Now this is awesome! With tests, that's a plus 1000. :D

this approach is actually really clever.

Several questions - Do we need a "windowsfeatures" added to chocolatey-uninstall? Can multiple features be specified on the same line? I know the dism /online /enable-feature can take an unlimited number of /featurename: switches.

LOVE THIS PR!

Aside:
I am going to modify the puppet chocolatey provider to support just the sources param, since everything else is "in place". . The more I think about it, the more I think chocolatey is the ultimate provider for puppet on windows.

I think adding a uninstall for these makes sense. I'll add that.

I do think that adding multiple features would be handy and should be faster since fewer round trips would be incurred. I didn't add it since it did not seem to mesh with the current chocolatey model of having a single package for each cinst. However, rather than making a special case for this feed, what would you think of adding the ability for any chocolatey feed (or atleast this one and chocolatey nuget) to accept an array of packages. That might be a nice overall enhancement. The challenge is that the normal CommandLine does not have an understanding of arrays but we might be able to change the .bat file generator to convert comma delimited arguments to arrays.

I think all should do that. It aligns well with other package managers. Just haven't yet gotten to that one.

Took a look at adding uninstall. While it looks pretty trivial for this feed. It seems like the current codebase is in need of a more pluggable pattern. Right now, each feed have dedicated scripts for install, webpi and winfeatures have inline conditionals for lists and uninstall only supports nuget.

I'd propose that each feed have their own dedicated script(s) for all functions and the Chocolatey-XXX function becomes a factory or just provides obviously common logic. There are a number of patterns that can be implemented. One suggestion:

• A provider, say webpi, has a entry script WePi-Provider.ps1
• Chocolatey exposes functions like Install-Strategy ([scriptblock] $InstallScript){ $InstallerRegistry[$source] = $installScript}
• $chocolatey exposes a $ChocolateyArgs that the plugin script can access ala $ChocolateyArgs.PackageName
• Chocolatey dot sources all the plugins when the module loads
• Chocolatey invokes the appropriate script when user invokes Chocolatey-XXX.

This is very rough and hardly baked but you get the idea. I'll post this on the forum and push this feed as is. Then we can create issues for plugins if we think this makes sense and also add another issue for supporting multiple packages.

Commenting on the chocolatey google group -
https://groups.google.com/forum/?fromgroups=#!topic/chocolatey/heV-XGc2ACw

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

On Thu, Sep 13, 2012 at 10:54 AM, Matt Wrock [email protected]:

Took a look at adding uninstall. While it looks pretty trivial for this
feed. It seems like the current codebase is in need of a more pluggable
pattern. Right now, each feed have dedicated scripts for install, webpi and
winfeatures have inline conditionals for lists and uninstall only supports
nuget.

I'd propose that each feed have their own dedicated script(s) for all
functions and the Chocolatey-XXX function becomes a factory or just
provides obviously common logic. There are a number of patterns that can be
implemented. One suggestion:

• A provider, say webpi, has a entry script WePi-Provider.ps1
• Chocolatey exposes functions like Install-Strategy ([scriptblock]
  $InstallScript){ $InstallerRegistry[$source] = $installScript}
• $chocolatey exposes a $ChocolateyArgs that the plugin script can
  access ala $ChocolateyArgs.PackageName
• Chocolatey dot sources all the plugins when the module loads
• Chocolatey invokes the appropriate script when user invokes
  Chocolatey-XXX.

This is very rough and hardly baked but you get the idea. I'll post this
on the forum and push this feed as is. Then we can create issues for
plugins if we think this makes sense and also add another issue for
supporting multiple packages.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/150#issuecomment-8533080.